Model-based diagnosis patterns for model checking

1 Context and challenges Model checking is a technique used to verify that a certain system's design satisfies its requirements. Given some models of the design and system's requirements formulated as formal properties, the system model can be checked [1], and if properties are violated, the model checker provides the user with counter examples that represent execution sequences (traces) leading to an unexpected situation. Then the engineer analyzes the cause of the problem, i.e. diagnosis activity, correct models or properties and carry out another verification endeavors. A verification process may include many verification endeavors gathering models and properties successively refined, which might be recorded in a dedicated form; stated deservedly by Ruys [2] to be a challenge. Diagnosing the cause of faulty properties is also a challenging task. Under the assumption formal properties are valid, and without neglecting the difficult problem to judge whether the formalized problem statement (model, properties) is an adequate description of the actual verification problem [3], we reduce here the scope to modeling errors. Model-based diagnosis (MBD) is a promising approach to diagnose modeling errors and consists in the interaction of observation and prediction [4] where observation indicates what the device is actually doing, and prediction indicates what it is supposed to do. " The interesting event is any difference between these two, a difference termed a discrepancy [5]. " MBD presumes that " if the model is correct, all the discrepancies between observation and prediction arise from defects of the device [5]. " Thereby diagnosis consists in identifying the faulty components responsible of the observed failure. When we apply this approach to model checking, the design is the system-understudy , and we need a correct model of the design to apply model-based reasoning. The diagnostician can be assisted by methods like Case-Based Reasoning (CBR) to dispose of a correct model. CBR consists in " solving a new problem by remembering a similar situation and by reusing information and knowledge of that situation [6]." Unfortunately these diagnostic methods/techniques are only possible if significant features about cases are identified and formalized. In conclusion, dealing with multiple data or diagnosing faults are challenges which require the verification's information to be well-defined and managed through time; to this intent we propose to define patterns facilitating information's formalization and sharing among engineers. We illustrate the idea through a verification scenario on a sample case, with a focus on diagnosis artifacts.